Hardware-in-the-loop is a known simulation technique that allows either parts of a simulation or the entire simulation to be operated by real operational hardware, such as sensors, radars, etc. Man-in-the-loop is a known simulation technique that allows a user to be in control of one or more systems used in a simulation, and the simulation does not run without interaction and control by the user.
In general, a simulation need not include a man-in-the-loop simulation or a hardware-in-the-loop simulation. A “virtual” simulation can operate only within one or more computer platforms, without real operational hardware and without human interaction as the simulation operates.
A simulation can be distributed, operating across multiple computing platforms, or it can be non-distributed, operating in one computing platform. A distributed simulation can include hardware-in-the-loop and/or man-in-the-loops simulations, or it can include only computing platforms, having little or no human interaction during operation of the simulation.
Man-in-the-loop, hardware-in-the-loop simulations, and virtual simulations can provide an environment in which to run scenarios having more than one simulation system. For example, a simulation of a military joint task force command (JTFC) can be coupled to a simulation of an airborne warning and control system (AWACS), providing a simulation of interactions between the JTFC and the AWACS. Either one or both of the simulations can be operated by a human operator (man-in-the-loop) as if the operator were using a real-world system, e.g., a real JTFC or AWACS as used in the field.
Man-in-the-loop, hardware-in-the-loop, and virtual simulations can support training, analysis, development, system integration, and test. Man-in-the-loop, hardware-in-the-loop, and virtual simulations are also useful to validate system designs.
High level architecture (HLA) is a known software structure for generating a high level computer simulation from a group of lower level computer simulations. The HLA provides a structure having rules by which software developers can generate individual lower level software simulations so that they are reusable and can be used by a variety of higher level simulations.
HLA simulations are composed of lower level simulations called “federates” which combine into a high level simulation called a “federation.” A federate can exist with multiple instances in a federation. For example, there can be several instances of a simulation of a particular weapons system, each a federate to a high level aircraft simulation, which can be the federation. Federates can also include system functions such as interfaces to human operators, interfaces to real operational hardware, and interfaces to general software functions such as data collection, data analysis, and data display. Federates can join and resign from a federation either statically or dynamically as the higher level simulation executes.
The HLA includes three components, HLA rules, HLA interface specifications, and an HLA object model template (OMTs). The HLA rules include both federation rules and federate rules. The federation rules include a requirement for a federation object model (FOM) in compliance with the OMT, and documentation thereof.
The federation rules also establish a run-time infrastructure (RTI) in compliance with the HLA interface specifications. The RTI includes software having an executive portion that runs globally, and client portions associated with each federate. The federate rules make use of the RTI and specify data exchange with other members of the federation by way of the RTI. The HLA interface specification identifies how federates interact with the federation and with each other.
As is known, a federation can include a hierarchy of “object classes,” “object instances” associated with the object classes, “object class attributes” associated with the object instances, and “object attribute values” associated with the object class attributes. When running, the federation generates the object attribute values (i.e., data). For example, an object class can be “aircraft,” object instances thereof can be “Boeing 747,” “Boeing 707,” etc., an object class attribute can be “altitude,” and an object attribute value can be “1000 feet.”
This relationship can be shown as a hierarchy along with the above example as indicated below.